babeldoc-devel — Babeldoc developer list

[Babeldoc-devel] babeldoc/modules/core/config/service query.properties,1.6,1.7

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

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

Modified Files:
	query.properties 
Log Message:
Added default error handler entry in service/config file. Note that this information is not used yet...

Index: query.properties
===================================================================
RCS file: /cvsroot/babeldoc/babeldoc/modules/core/config/service/query.properties,v
retrieving revision 1.6
retrieving revision 1.7
diff -C2 -d -r1.6 -r1.7
*** query.properties	9 Jun 2003 23:31:14 -0000	1.6
--- query.properties	25 Jun 2003 14:00:18 -0000	1.7
***************
*** 26,29 ****
--- 26,31 ----
  PipelineStageFactory.xml=com.babeldoc.core.pipeline.xml.XmlPipelineStageFactory
  
+ PipelineStageErrorHandler.default=com.babeldoc.core.pipeline.DefaultPipelineStageErrorHandler
+ 
  Command.journal=com.babeldoc.core.journal.command.JournalCommand
  Command.pipeline=com.babeldoc.core.pipeline.command.PipelineCommand

Re: [Babeldoc-devel] On how to commit

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

On how to commitHi Vincent


> - The addMessage tin the error handler saves the complete statck trace in
case of exception (with jakarta commans lang ExceptionUtils)



To be honest this method was a workaround for some problems I had (I needed
some way to inform users what happend to their document). I guess there are
better ways of doing it. At least, I don't like this method's name. But if
you have found this method usefull - feel free to change it.

> - SmtpWriter will not add a Body in case smtpMessage is blank (A blank
body is not good, No body is better) : else that breaks smtp/x400 gateway



OK. I like that. I guess this won't break existing pipelines, right?

> - I added some velocity pages to see only failed tickets, and in general
to make the web console look a bit nicer.  This is a place where I ant to do
some more in the near future.



Cool. We need much improvements here. I think that part of Babeldoc is still
in the same state as before.

>  - The Lock mechanism on FtpWriter : optional parameter to send a lock
file before sending the file and look if it does not exist before sending
them



I guess it is OK as long as this stage works as before when locks are not
used.
>  - etc.
> Are you OK with these ?
> I have done all that on branch 1.0 so I want now to patch back the main
branch.


Excelent. I am OK with all these. Others? Vincent, could you also update
changes file?

> I have seen the changes on the scanner : It is great but at the same time,
running babeldoc in "synchronized" mode is sometimes more easy to debug
(else the threads gets mixed together) : Have you think a parameter at the
scanner level to force it to work "as before" in synchronize mode ?


Scanner module is still in development phase. I haven't switched all workers
to use new way of feeding. As you might noticed scanner works with IFeeder,
so it could work with Synchronous and Asynchronous feeder. It will use
ScannerFactory to get IFeeder implementation class. Right now, this method d
oes not use configuration file - it is hardcoded and it only returns new
Asynchronous feeder. But we plan to make that configurable, too.

What is your opinion is it better to keep this configuration in separate
file or it should be part of scanner configuration? Also, should this be
hardcoded (something like switch) or we should let users to specify its
implementation class like we do with ScanerWorkers? That way users will have
more freedom but currently I don't see some benefits of it!


All, note that 1.1 release will  be developmental - many new features but
not stable enough. I suggest we should soon release one stable version -
1.0.2 with Vincent's changes, and probably some other changes. Are you all
OK with that? Are there other changes/fixes we should put in this release?


Dejan

[Babeldoc-devel] On how to commit

[Vincent H. <vin...@hu...>]

Hi,
I got CVS access to commit changes to change some private methods to
protected.
Now I have done some more small corrections in different areas.  I would
like to know if you want to see these changes before I commit them.
Some changes I have done:
 - The addMessage tin the error handler saves the complete statck trace =
in
case of exception (with jakarta commans lang ExceptionUtils)
 - SmtpWriter will not add a Body in case smtpMessage is blank (A blank =
body
is not good, No body is better) : else that breaks smtp/x400 gateway
 - I added some velocity pages to see only failed tickets, and in =
general to
make the web console look a bit nicer.  This is a place where I ant to =
do
some more in the near future.
 - The Lock mechanism on FtpWriter : optional parameter to send a lock =
file
before sending the file and look if it does not exist before sending =
them
 - etc.
Are you OK with these ?

I have done all that on branch 1.0 so I want now to patch back the main
branch.
I have seen the changes on the scanner : It is great but at the same =
time,
running babeldoc in "synchronized" mode is sometimes more easy to debug
(else the threads gets mixed together) : Have you think a parameter at =
the
scanner level to force it to work "as before" in synchronize mode ?

Cheers,
Vincent

Re: [Babeldoc-devel] Making PipelineStage.getErrorHandler() protected

[Stefan K. <ste...@co...>]

The service/config approach is the right way. The "method override" would
only work for all self-developed stages and not for the babeldoc standard
stages. So, this won't really help us. I haven't recognized this fact
earlier.

Stefan

----- Original Message -----
From: "Dejan Krsmanovic" <dej...@nb...>
To: <bab...@li...>
Sent: Tuesday, June 24, 2003 8:49 AM
Subject: Re: [Babeldoc-devel] Making PipelineStage.getErrorHandler()
protected


> Maybe better idea is using service/config.properties file. We could add
new
> property with  name defaultErrorHandler and value of the class wich should
> be used as default error handler... By default this value should be
> com.babeldoc.core.pipeline.DefaultPipelineStageErrorHandler but you you
> could put whatever value you want...
>
> That way you don't need to change code...
>
> We could also made getErrorHandler protected so it can be overiden. I
guess
> it became private during refactoring, that is - Eclipse made it private
not
> me! ;)
>
> Note that you could also use errorStage property to change processing
order
> in case of exceptions. So you can route to SmtpWriter in case of
> exceptions...
>
> What do you think, which solution is best for you?
>
> Dejan
>
>
>
>
> ----- Original Message -----
> From: "Stefan Krieger" <ste...@co...>
> To: <bab...@li...>
> Sent: Monday, June 23, 2003 10:51 PM
> Subject: [Babeldoc-devel] Making PipelineStage.getErrorHandler() protected
>
>
> > Hello,
> >
> > We am using babeldoc in a document transformation project in a J2EE
> > environment.
> > We would like to send eMails in case of exceptions during PipelineStage
> > processing. This should be the default ErrorHandler for all
PipelineStages
> > we are running. Unfortunately, the method getErrorHandler() in
> PipelineStage
> > is private. So, we are forced to configure our ErrorHandler for alle
> > PipelineStages otherwise DefaultPipelineStageErrorHandler is always
> > returned. Can you make this method "protected" ?
> > Or, even better: provide a factory method for the DefaultErrorHandler:
> >
> > protected IPipelineStageErrorHandler createDefaultErrorHandler() {
return
> > new DefaultPipelineStageErrorHandler() ; }
> >
> > Then we can reuse the configuration part in getErrorHandler().
> >
> > Thanks,
> > Stefan
> >
> >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by: INetU
> > Attention Web Developers & Consultants: Become An INetU Hosting Partner.
> > Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
> > INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
> > _______________________________________________
> > Babeldoc-devel mailing list
> > Bab...@li...
> > https://lists.sourceforge.net/lists/listinfo/babeldoc-devel
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: INetU
> Attention Web Developers & Consultants: Become An INetU Hosting Partner.
> Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
> INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
> _______________________________________________
> Babeldoc-devel mailing list
> Bab...@li...
> https://lists.sourceforge.net/lists/listinfo/babeldoc-devel
>

Re: [Babeldoc-devel] Making PipelineStage.getErrorHandler() protected

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

Maybe better idea is using service/config.properties file. We could add new
property with  name defaultErrorHandler and value of the class wich should
be used as default error handler... By default this value should be
com.babeldoc.core.pipeline.DefaultPipelineStageErrorHandler but you you
could put whatever value you want...

That way you don't need to change code...

We could also made getErrorHandler protected so it can be overiden. I guess
it became private during refactoring, that is - Eclipse made it private not
me! ;)

Note that you could also use errorStage property to change processing order
in case of exceptions. So you can route to SmtpWriter in case of
exceptions...

What do you think, which solution is best for you?

Dejan




----- Original Message -----
From: "Stefan Krieger" <ste...@co...>
To: <bab...@li...>
Sent: Monday, June 23, 2003 10:51 PM
Subject: [Babeldoc-devel] Making PipelineStage.getErrorHandler() protected


> Hello,
>
> We am using babeldoc in a document transformation project in a J2EE
> environment.
> We would like to send eMails in case of exceptions during PipelineStage
> processing. This should be the default ErrorHandler for all PipelineStages
> we are running. Unfortunately, the method getErrorHandler() in
PipelineStage
> is private. So, we are forced to configure our ErrorHandler for alle
> PipelineStages otherwise DefaultPipelineStageErrorHandler is always
> returned. Can you make this method "protected" ?
> Or, even better: provide a factory method for the DefaultErrorHandler:
>
> protected IPipelineStageErrorHandler createDefaultErrorHandler() { return
> new DefaultPipelineStageErrorHandler() ; }
>
> Then we can reuse the configuration part in getErrorHandler().
>
> Thanks,
> Stefan
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: INetU
> Attention Web Developers & Consultants: Become An INetU Hosting Partner.
> Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
> INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
> _______________________________________________
> Babeldoc-devel mailing list
> Bab...@li...
> https://lists.sourceforge.net/lists/listinfo/babeldoc-devel

[Babeldoc-devel] Making PipelineStage.getErrorHandler() protected

[Stefan K. <ste...@co...>]

Hello,

We am using babeldoc in a document transformation project in a J2EE
environment.
We would like to send eMails in case of exceptions during PipelineStage
processing. This should be the default ErrorHandler for all PipelineStages
we are running. Unfortunately, the method getErrorHandler() in PipelineStage
is private. So, we are forced to configure our ErrorHandler for alle
PipelineStages otherwise DefaultPipelineStageErrorHandler is always
returned. Can you make this method "protected" ?
Or, even better: provide a factory method for the DefaultErrorHandler:

protected IPipelineStageErrorHandler createDefaultErrorHandler() { return
new DefaultPipelineStageErrorHandler() ; }

Then we can reuse the configuration part in getErrorHandler().

Thanks,
Stefan

[Babeldoc-devel] GPL dependency

[Ken G. <kg...@sp...>]

I realized last night that since Babeldoc has moved to the Apache 
license, we really need to break its dependency on the Ostermiller utils 
library which is GPLed.  Ideally this should be done before the next 
official release.


Ken

[Babeldoc-devel] Re: axis

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

Hans,

I have never used suns soap stuff but have found axis to be an exciting and 
reliable software framework.  I definitely think moving to use it would be a 
good idea.  If you need any help getting the dynamic class loading working, 
please email the list and we can work on it.   Your ideas make sense - using 
soap as a universal document transport layer makes a lot of sense *if* we can 
do it with reasonable performance.

regards,
Bruce.

On Wednesday 18 June 2003 07:47 am, Hans Benedict wrote:
> On Tue, 17 Jun 2003, Bruce McDonald wrote:
> > I noticed that axis 1.1 has been released.  Is this something that we
> > should look at incorporating into babeldoc?
>
> After some bad experiences with Sun's jwsdp, I will definitely look at it.
>
> As soon as I have understood the dynamic class loading in babeldoc (;-)),
> I will try to write a SoapHelper implementation for axis and make
> configurable, which one is used. All the other soap classes should work
> anyway.
>
> Or did you mean something more innovative with 'incorporating'? Perhaps we
> should collect some ideas for the future of the soap module. Things I am
> thinking about are:
>
> - something like a SoapTransformer service, that takes a document via SOAP
>   and gives the result of some transformation back
>
> - connection two pipelines via soap
>
> - use other transports than http (mail, jms)
>
>
> Regards,
> Hans

Re: [Babeldoc-devel] axis

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

> - something like a SoapTransformer service, that takes a document via SOAP
>   and gives the result of some transformation back

I think this could be very usefull.

>
> - connection two pipelines via soap

I guess the first item is prerequisite for this one, right?!

>
> - use other transports than http (mail, jms)

I don't think this one is very important. Everybody use HTTP protocol for
web services anyway. Of course if you want, do it! ;)

Dejan
>
>
> Regards,
> Hans
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: INetU
> Attention Web Developers & Consultants: Become An INetU Hosting Partner.
> Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
> INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
> _______________________________________________
> Babeldoc-devel mailing list
> Bab...@li...
> https://lists.sourceforge.net/lists/listinfo/babeldoc-devel

[Babeldoc-devel] axis

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

On Tue, 17 Jun 2003, Bruce McDonald wrote:

> I noticed that axis 1.1 has been released.  Is this something that we should
> look at incorporating into babeldoc?

After some bad experiences with Sun's jwsdp, I will definitely look at it.

As soon as I have understood the dynamic class loading in babeldoc (;-)),
I will try to write a SoapHelper implementation for axis and make
configurable, which one is used. All the other soap classes should work
anyway.

Or did you mean something more innovative with 'incorporating'? Perhaps we
should collect some ideas for the future of the soap module. Things I am
thinking about are:

- something like a SoapTransformer service, that takes a document via SOAP
  and gives the result of some transformation back

- connection two pipelines via soap

- use other transports than http (mail, jms)


Regards,
Hans

Re: [Babeldoc-devel] Jalopy task

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

Hans,

I noticed that axis 1.1 has been released.  Is this something that we should 
look at incorporating into babeldoc?

regards,
Bruce.

On Wednesday 11 June 2003 07:35 am, Hans Benedict wrote:
> I had to change the CVS substitution mode for babeldocconvention.xml,
> because jalopy complained about unexpected characters in end tags (?!?).
> Now it works again.
>
> I also added "The Apache Software License" to the keys for headers that
> should be removed, because otherwise the header will be added again and
> again...
>
> This makes the $Log$ keyword in this header somewhat useless, but it tends
> to give problems with branch merges, anyway.
>
> Regards,
> Hans
>
> On Tue, 10 Jun 2003, Bruce McDonald wrote:
> > Hans, All:
> >
> > Thank you Hans!  This is just what is needed.  I have gone ahead and
> > updated your convention.xml to place the APL header on each of the java
> > source files. I have also remove those separator characters.  I have run
> > this on the init source files and I will commit them so that you can look
> > at the results. Please comment.
> >
> > regards,
> > Bruce.
> >
> > On Tuesday 10 June 2003 12:17 pm, Hans Benedict wrote:
> > > On Tue, 10 Jun 2003, Dejan Krsmanovic wrote:
> > > > Hans, could you add jalopy task to build.xml file (files)? Libraries
> > > > for jalopy should be stored under support folder since they are not
> > > > needed at runtime.
> > > > Task should be optional - it should not be executed by default.
> > >
> > > O.k., I put it into CVS. The new task is called "format". At the moment
> > > it is actually only used for the soap module, because there will be
> > > some problems in the beginning, mainly concerning javadoc comment. For
> > > example: jalopy crashes in SqlEnrichPipelineStage due to an "<a
> > > href=..." in the @author tag.
> > >
> > > I suggest that everybody tests the modules he feels responsible for
> > > (;-)) by removing the comment in the corresponding build.xml.
> > >
> > > I left in the "destdir"-attribute, which means that the modified
> > > files go to ./tmp/format. If you are happy with the result, please
> > > remove the line with the destdir attribute, so that the source files
> > > get overridden, and then recommit the files to CVS.
> > >
> > > I also found, that jalopy takes rather a long time to parse something
> > > in core/journal, but I have no idea, what is happening there.
> > >
> > > Bruce, the header text lives in support/jalopy/babeldocconvention.xml.
> > > If you change it there, it can be changed in the source files as well.
> > > You can either change it manually or use
> > > ./support/jalopy/bin/preferences.sh (It seems, there is no commandline
> > > argument for the file, so you will have to use the Import/Export
> > > buttons.)
> > >
> > > Good luck,
> > > Hans
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > This SF.net email is sponsored by:  Etnus, makers of TotalView, The
> > > best thread debugger on the planet. Designed with thread debugging
> > > features you've never dreamed of, try TotalView 6 free at
> > > www.etnus.com. _______________________________________________
> > > Babeldoc-devel mailing list
> > > Bab...@li...
> > > https://lists.sourceforge.net/lists/listinfo/babeldoc-devel
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
> > thread debugger on the planet. Designed with thread debugging features
> > you've never dreamed of, try TotalView 6 free at www.etnus.com.
> > _______________________________________________
> > Babeldoc-devel mailing list
> > Bab...@li...
> > https://lists.sourceforge.net/lists/listinfo/babeldoc-devel
>
> -------------------------------------------------------
> This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
> thread debugger on the planet. Designed with thread debugging features
> you've never dreamed of, try TotalView 6 free at www.etnus.com.
> _______________________________________________
> Babeldoc-devel mailing list
> Bab...@li...
> https://lists.sourceforge.net/lists/listinfo/babeldoc-devel

Re: [Babeldoc-devel] VariableProcessor

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

Ok,

We might need to work together to coordinate this stuff - keep in touch.

Please commit the postgresql stuff - that is very nice to have.

regards,
Bruce.

On Monday 16 June 2003 08:19 pm, Ken Geis wrote:
> Done.
>
> I just realized that I never checked in my PostgreSQL scripts and
> PostgreSqlJournal implementation.  I'll do that soon.
>
> In the next few days, I will be working on ConfigService to try out
> commons-discovery.  It might cause some changes (instead of
> -Dbabel.config=FooConfig, you may need to do
> -Dcom.babeldoc.core.config.IConfigService=FooConfig.  If that is not
> acceptable, I can code it to check babel.config first.  In any case, I
> need to change the use of Class.forName() to
> Thread.currentThread().getContextClassLoader() for use in J2EE
> environments.
>
> Bruce McDonald wrote:
> > Thats a good point.  On the face of it, it looks like the addToContext
> > method should be synchronized.  Can you make the change.
> >
> > regards,
> > Bruce.
> >
> > On Monday 16 June 2003 06:38 pm, Ken Geis wrote:
> >>I was looking at the code to com.babeldoc.core.VariableProcessor.  I
> >>have a little problem with it.
> >>
> >>Why is getContext() synchronized?  No other method in VariableProcessor
> >>is synchronized.  This means that you are trying to avoid having two
> >>threads attain a reference to the context at the same time.  It makes no
> >>assurance on synchronizing accesses to the methods on the context
> >>object.  I could understand synchronizing addToContext(name, object).
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: INetU
> Attention Web Developers & Consultants: Become An INetU Hosting Partner.
> Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
> INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
> _______________________________________________
> Babeldoc-devel mailing list
> Bab...@li...
> https://lists.sourceforge.net/lists/listinfo/babeldoc-devel

Re: [Babeldoc-devel] VariableProcessor

[Ken G. <kg...@sp...>]

Done.

I just realized that I never checked in my PostgreSQL scripts and 
PostgreSqlJournal implementation.  I'll do that soon.

In the next few days, I will be working on ConfigService to try out 
commons-discovery.  It might cause some changes (instead of 
-Dbabel.config=FooConfig, you may need to do 
-Dcom.babeldoc.core.config.IConfigService=FooConfig.  If that is not 
acceptable, I can code it to check babel.config first.  In any case, I 
need to change the use of Class.forName() to 
Thread.currentThread().getContextClassLoader() for use in J2EE environments.

Bruce McDonald wrote:
> Thats a good point.  On the face of it, it looks like the addToContext method 
> should be synchronized.  Can you make the change.
> 
> regards,
> Bruce.
> 
> On Monday 16 June 2003 06:38 pm, Ken Geis wrote:
> 
>>I was looking at the code to com.babeldoc.core.VariableProcessor.  I
>>have a little problem with it.
>>
>>Why is getContext() synchronized?  No other method in VariableProcessor
>>is synchronized.  This means that you are trying to avoid having two
>>threads attain a reference to the context at the same time.  It makes no
>>assurance on synchronizing accesses to the methods on the context
>>object.  I could understand synchronizing addToContext(name, object).

Re: [Babeldoc-devel] VariableProcessor

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

Thats a good point.  On the face of it, it looks like the addToContext method 
should be synchronized.  Can you make the change.

regards,
Bruce.

On Monday 16 June 2003 06:38 pm, Ken Geis wrote:
> I was looking at the code to com.babeldoc.core.VariableProcessor.  I
> have a little problem with it.
>
> Why is getContext() synchronized?  No other method in VariableProcessor
> is synchronized.  This means that you are trying to avoid having two
> threads attain a reference to the context at the same time.  It makes no
> assurance on synchronizing accesses to the methods on the context
> object.  I could understand synchronizing addToContext(name, object).
>
>
> Ken
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: INetU
> Attention Web Developers & Consultants: Become An INetU Hosting Partner.
> Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
> INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
> _______________________________________________
> Babeldoc-devel mailing list
> Bab...@li...
> https://lists.sourceforge.net/lists/listinfo/babeldoc-devel

[Babeldoc-devel] VariableProcessor

[Ken G. <kg...@sp...>]

I was looking at the code to com.babeldoc.core.VariableProcessor.  I 
have a little problem with it.

Why is getContext() synchronized?  No other method in VariableProcessor 
is synchronized.  This means that you are trying to avoid having two 
threads attain a reference to the context at the same time.  It makes no 
assurance on synchronizing accesses to the methods on the context 
object.  I could understand synchronizing addToContext(name, object).


Ken

Re: [Babeldoc-devel] [Fwd: [ babeldoc-Bugs-753907 ] FtpWriter.sendFtpMessage should not be static]

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

I think we could make this method non-static. Currently, there is no need
for it to be static. I think this could be case for some other methods, too.
You can change method signature and subclass this class or you can try to
implement locking in FtpWriter class. If you decide to implement this in
base class make sure it is configurable usign options. Also, for backward
compatibility this option should not be mandatory and default behaviour
should remain the same.
If you implement this you can send us patch. We will be glad to support this
feature in Babeldoc.

You should avoid extending Mailbox scanner because this class will change a
lot in the next release. We have introduced asynchronous feeding and
scanners will use it. In a few words, scanner will scan for new documents,
and when it found new one, it will just feed it in feeder. Another thread in
feeder will do processing of document. That way, scanning of messages will
be much faster since there will be no waiting for processing of document.
This is very important for mailbox scanner since mail server connections
will be much shorter.

Anyway, one of changes we are planning to do in scanners is removing inner
classes that implements IScanDocuments interface since there will be no need
for them. Now each scanner worker will put scanned document in feeder when
it found new. Much of complexity in inner classes will be removed this way.
So, I suggest you to wait until next release or to update from CVS within
few days, when I finish implementing this feature.

Dejan


> In FtpWriter I have to work with lock files : I can not PUT the file if a
> Lock file exists and I create/delete a Lock file before/after sending the
> file.  Semaphore is another word for that...  I never trusts FTP servers
> to do that for me.
> So
> I extend the FtpWriter but since a static method can not be extend I was
> blocked and had to change the babeldoc class itself (or I could rewrite
> all the class)
> I had a similar issues when customising by MailboxScanner for adding
> Filter (see another SF enhancement request).  Because the inner class was
> package protected I could not extend and add to copy/paste the class
> (beurk)
>
> These are small issues and I don't know your priorities so I am just
> dumping the ideas right now.
>
> To do the task completely there will be a need for read all classes and
> remove private/package protected definitions, remove static methods and,
> maybe, work less with inner classes (I always find it more difficult to
> inherit from Class containing inner classes)
>
> Vincent
>
> -------- Original Message --------
> Subject: [ babeldoc-Bugs-753907 ] FtpWriter.sendFtpMessage should not be
> static
> From: "SourceForge.net" <no...@so...>
> Date: Fri, June 13, 2003 15:49
> To: no...@so...
>
> Bugs item #753907, was opened at 2003-06-13 13:32
> Message generated for change (Comment added) made by dejank
> You can respond by visiting:
>
https://sourceforge.net/tracker/?func=detail&atid=482496&aid=753907&group_id
=56976
>
> Category: None
> Group: None
> Status: Open
> Resolution: None
> Priority: 5
> Submitted By: Vincent Harcq (vharcq)
> Assigned to: Nobody/Anonymous (nobody)
> Summary: FtpWriter.sendFtpMessage should not be static
>
> Initial Comment:
> ...to be able to extend the class and overwrite the
> method to create a custom FtpWriter
>
> Vincent
>
> ----------------------------------------------------------------------
>
> >Comment By: Dejan Krsmanovic (dejank)
> Date: 2003-06-13 15:49
>
> Message:
> Logged In: YES
> user_id=608954
>
> There are few other static methods in several pipeline stages.
> I guess the main reason for this is that they could be easily
> used in other stages (Bruce?). But except parse method of
> Domify stage I cannot recall if any other stage use methods
> of other stages.
>
> I think we should discuss of this issue. I suggest you to
> subscribe to developer list (if you are not already) so we
> could discuss about this.
>
>
>
> ----------------------------------------------------------------------
>
> You can respond by visiting:
>
https://sourceforge.net/tracker/?func=detail&atid=482496&aid=753907&group_id
=56976
>
>
>
>
>
> -------------------------------------------------------
> This SF.NET email is sponsored by: eBay
> Great deals on office technology -- on eBay now! Click here:
> http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
> _______________________________________________
> Babeldoc-devel mailing list
> Bab...@li...
> https://lists.sourceforge.net/lists/listinfo/babeldoc-devel

[Babeldoc-devel] [Fwd: [ babeldoc-Bugs-753907 ] FtpWriter.sendFtpMessage should not be static]

[Vincent H. <vin...@hu...>]

Hi,
I restart this from a SF bug report

Babeldoc have a really nice way to handle module, so that I can create my
own module by extending some scanners or pipelines.
I got one issue that is to extend (in Java sense) some exsting classes and
overwrite the methods I needed.
In FtpWriter I have to work with lock files : I can not PUT the file if a
Lock file exists and I create/delete a Lock file before/after sending the
file.  Semaphore is another word for that...  I never trusts FTP servers
to do that for me.
So
I extend the FtpWriter but since a static method can not be extend I was
blocked and had to change the babeldoc class itself (or I could rewrite
all the class)
I had a similar issues when customising by MailboxScanner for adding
Filter (see another SF enhancement request).  Because the inner class was
package protected I could not extend and add to copy/paste the class
(beurk)

These are small issues and I don't know your priorities so I am just
dumping the ideas right now.

To do the task completely there will be a need for read all classes and
remove private/package protected definitions, remove static methods and,
maybe, work less with inner classes (I always find it more difficult to
inherit from Class containing inner classes)

Vincent

-------- Original Message --------
Subject: [ babeldoc-Bugs-753907 ] FtpWriter.sendFtpMessage should not be
static
From: "SourceForge.net" <no...@so...>
Date: Fri, June 13, 2003 15:49
To: no...@so...

Bugs item #753907, was opened at 2003-06-13 13:32
Message generated for change (Comment added) made by dejank
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=482496&aid=753907&group_id=56976

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Vincent Harcq (vharcq)
Assigned to: Nobody/Anonymous (nobody)
Summary: FtpWriter.sendFtpMessage should not be static

Initial Comment:
...to be able to extend the class and overwrite the
method to create a custom FtpWriter

Vincent

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

>Comment By: Dejan Krsmanovic (dejank)
Date: 2003-06-13 15:49

Message:
Logged In: YES
user_id=608954

There are few other static methods in several pipeline stages.
I guess the main reason for this is that they could be easily
used in other stages (Bruce?). But except parse method of
Domify stage I cannot recall if any other stage use methods
of other stages.

I think we should discuss of this issue. I suggest you to
subscribe to developer list (if you are not already) so we
could discuss about this.



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

You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=482496&aid=753907&group_id=56976

Re: [Babeldoc-devel] Jalopy task

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

I had to change the CVS substitution mode for babeldocconvention.xml,
because jalopy complained about unexpected characters in end tags (?!?).
Now it works again.

I also added "The Apache Software License" to the keys for headers that
should be removed, because otherwise the header will be added again and
again...

This makes the $Log$ keyword in this header somewhat useless, but it tends
to give problems with branch merges, anyway.

Regards,
Hans

On Tue, 10 Jun 2003, Bruce McDonald wrote:

> Hans, All:
>
> Thank you Hans!  This is just what is needed.  I have gone ahead and updated
> your convention.xml to place the APL header on each of the java source files.
> I have also remove those separator characters.  I have run this on the init
> source files and I will commit them so that you can look at the results.
> Please comment.
>
> regards,
> Bruce.
>
> On Tuesday 10 June 2003 12:17 pm, Hans Benedict wrote:
> > On Tue, 10 Jun 2003, Dejan Krsmanovic wrote:
> > > Hans, could you add jalopy task to build.xml file (files)? Libraries for
> > > jalopy should be stored under support folder since they are not needed at
> > > runtime.
> > > Task should be optional - it should not be executed by default.
> >
> > O.k., I put it into CVS. The new task is called "format". At the moment it
> > is actually only used for the soap module, because there will be some
> > problems in the beginning, mainly concerning javadoc comment. For example:
> > jalopy crashes in SqlEnrichPipelineStage due to an "<a href=..." in the
> > @author tag.
> >
> > I suggest that everybody tests the modules he feels responsible for (;-))
> > by removing the comment in the corresponding build.xml.
> >
> > I left in the "destdir"-attribute, which means that the modified
> > files go to ./tmp/format. If you are happy with the result, please remove
> > the line with the destdir attribute, so that the source files get
> > overridden, and then recommit the files to CVS.
> >
> > I also found, that jalopy takes rather a long time to parse something in
> > core/journal, but I have no idea, what is happening there.
> >
> > Bruce, the header text lives in support/jalopy/babeldocconvention.xml. If
> > you change it there, it can be changed in the source files as well. You
> > can either change it manually or use ./support/jalopy/bin/preferences.sh
> > (It seems, there is no commandline argument for the file, so you will have
> > to use the Import/Export buttons.)
> >
> > Good luck,
> > Hans
> >
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
> > thread debugger on the planet. Designed with thread debugging features
> > you've never dreamed of, try TotalView 6 free at www.etnus.com.
> > _______________________________________________
> > Babeldoc-devel mailing list
> > Bab...@li...
> > https://lists.sourceforge.net/lists/listinfo/babeldoc-devel
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
> thread debugger on the planet. Designed with thread debugging features
> you've never dreamed of, try TotalView 6 free at www.etnus.com.
> _______________________________________________
> Babeldoc-devel mailing list
> Bab...@li...
> https://lists.sourceforge.net/lists/listinfo/babeldoc-devel
>

Re: [Babeldoc-devel] Jalopy task

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

Hans, All:

Thank you Hans!  This is just what is needed.  I have gone ahead and updated 
your convention.xml to place the APL header on each of the java source files.  
I have also remove those separator characters.  I have run this on the init 
source files and I will commit them so that you can look at the results.  
Please comment.

regards,
Bruce.

On Tuesday 10 June 2003 12:17 pm, Hans Benedict wrote:
> On Tue, 10 Jun 2003, Dejan Krsmanovic wrote:
> > Hans, could you add jalopy task to build.xml file (files)? Libraries for
> > jalopy should be stored under support folder since they are not needed at
> > runtime.
> > Task should be optional - it should not be executed by default.
>
> O.k., I put it into CVS. The new task is called "format". At the moment it
> is actually only used for the soap module, because there will be some
> problems in the beginning, mainly concerning javadoc comment. For example:
> jalopy crashes in SqlEnrichPipelineStage due to an "<a href=..." in the
> @author tag.
>
> I suggest that everybody tests the modules he feels responsible for (;-))
> by removing the comment in the corresponding build.xml.
>
> I left in the "destdir"-attribute, which means that the modified
> files go to ./tmp/format. If you are happy with the result, please remove
> the line with the destdir attribute, so that the source files get
> overridden, and then recommit the files to CVS.
>
> I also found, that jalopy takes rather a long time to parse something in
> core/journal, but I have no idea, what is happening there.
>
> Bruce, the header text lives in support/jalopy/babeldocconvention.xml. If
> you change it there, it can be changed in the source files as well. You
> can either change it manually or use ./support/jalopy/bin/preferences.sh
> (It seems, there is no commandline argument for the file, so you will have
> to use the Import/Export buttons.)
>
> Good luck,
> Hans
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
> thread debugger on the planet. Designed with thread debugging features
> you've never dreamed of, try TotalView 6 free at www.etnus.com.
> _______________________________________________
> Babeldoc-devel mailing list
> Bab...@li...
> https://lists.sourceforge.net/lists/listinfo/babeldoc-devel

[Babeldoc-devel] GUI Journal Browser

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

All,

I have just commited a GUI journal browser - its just a proof of concept:

babeldoc journalbrowser

Have fun.

regards,
Bruce.

[Babeldoc-devel] New module - no more classpath blues

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

All,

I have just committed a new module called init.  What this module does is to 
automatically load the jars and zips in the BABELDOC_HOME directory into the 
a URLClassLoader and then to load babeldoc using this classloader.  This 
means that those long, long classpaths are now a thing of the past.  This 
code is very simple but there are potential issues.  I had to deal with one 
with JS.JAR (rhino) - basically resolved it by making the babeldoc_init.jar 
(the init module jar) dependant on the js.jar archive.  If you happen across 
any other funny business, let me know.  If you dont want to use this module, 
then just delete modules/init and everything is as it was.

I also changed the BABELDOC_USER system property from babelCfgPath to 
babeldoc.user just like the babeldoc.home property - I edited the start up 
scripts accordingly.  You should not notice any difference.

regards,
Bruce.

Re: P.S. to Re: [Babeldoc-devel] Jalopy task

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

OK. I will test it tomorrow at office. 

Dejan

--- Hans Benedict <ben...@ch...> wrote:
> I forgot something: I also had to change build.sh
> and build.bat in order
> to get the jalopy libs in. But I could only test
> build.sh. Dejan, you are
> working on a windows box, aren't you? Could you
> please test it?
> 
> Regards,
> Hans
> 
> 
> 
>
-------------------------------------------------------
> This SF.net email is sponsored by:  Etnus, makers of
> TotalView, The best
> thread debugger on the planet. Designed with thread
> debugging features
> you've never dreamed of, try TotalView 6 free at
> www.etnus.com.
> _______________________________________________
> Babeldoc-devel mailing list
> Bab...@li...
>
https://lists.sourceforge.net/lists/listinfo/babeldoc-devel


__________________________________
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com

P.S. to Re: [Babeldoc-devel] Jalopy task

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

I forgot something: I also had to change build.sh and build.bat in order
to get the jalopy libs in. But I could only test build.sh. Dejan, you are
working on a windows box, aren't you? Could you please test it?

Regards,
Hans

Re: [Babeldoc-devel] Jalopy task

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

On Tue, 10 Jun 2003, Dejan Krsmanovic wrote:

> Hans, could you add jalopy task to build.xml file (files)? Libraries for
> jalopy should be stored under support folder since they are not needed at
> runtime.
> Task should be optional - it should not be executed by default.

O.k., I put it into CVS. The new task is called "format". At the moment it
is actually only used for the soap module, because there will be some
problems in the beginning, mainly concerning javadoc comment. For example:
jalopy crashes in SqlEnrichPipelineStage due to an "<a href=..." in the
@author tag.

I suggest that everybody tests the modules he feels responsible for (;-))
by removing the comment in the corresponding build.xml.

I left in the "destdir"-attribute, which means that the modified
files go to ./tmp/format. If you are happy with the result, please remove
the line with the destdir attribute, so that the source files get
overridden, and then recommit the files to CVS.

I also found, that jalopy takes rather a long time to parse something in
core/journal, but I have no idea, what is happening there.

Bruce, the header text lives in support/jalopy/babeldocconvention.xml. If
you change it there, it can be changed in the source files as well. You
can either change it manually or use ./support/jalopy/bin/preferences.sh
(It seems, there is no commandline argument for the file, so you will have
to use the Import/Export buttons.)

Good luck,
Hans

[Babeldoc-devel] Jalopy task

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

Great!
Hans, could you add jalopy task to build.xml file (files)? Libraries for
jalopy should be stored under support folder since they are not needed at
runtime.
Task should be optional - it should not be executed by default.

Dejan

----- Original Message -----
From: "Hans Benedict" <ben...@ch...>
To: <bab...@li...>
Cc: "Dejan Krsmanovic" <dej...@nb...>
Sent: Tuesday, June 10, 2003 1:56 PM
Subject: Re: [Babeldoc-devel] Proposal for all the babeldoc developers -
CALL FOR VOTE


> Dejan,
>
> yes, it identifies the header comment by keys like "babeldoc:  universal
> document processor", deletes it and replaces it with something else (or
> the same).
>
> cf. http://jalopy.sourceforge.net/header.html
>
> Regards,
> Hans
>
> On Tue, 10 Jun 2003, Dejan Krsmanovic wrote:
>
> > I agree with Hans. We need Jalopy anyway for code formatting. If it can
add
> > header to all sources than this is just one reason more to use it. Hans,
can
> > Jalopy remove old headers too?
> >
> > Dejan
> >
> >
> > > In case you haven't started yet: It could also be a job for jalopy.
And if
> > > we touch and recommit all the files anyway, it would be a good moment
to
> > > add the jalopy target to the build files.
> > >
> >
> >
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
> > thread debugger on the planet. Designed with thread debugging features
> > you've never dreamed of, try TotalView 6 free at www.etnus.com.
> > _______________________________________________
> > Babeldoc-devel mailing list
> > Bab...@li...
> > https://lists.sourceforge.net/lists/listinfo/babeldoc-devel
> >
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
> thread debugger on the planet. Designed with thread debugging features
> you've never dreamed of, try TotalView 6 free at www.etnus.com.
> _______________________________________________
> Babeldoc-devel mailing list
> Bab...@li...
> https://lists.sourceforge.net/lists/listinfo/babeldoc-devel