[DIGESTER] can stack trace be turned off?
I'm using digester in a utility that checks to see if a particular
document has been added to a web service repository. If the document
exists it is returned and digester parses it without error. If the
document does not exist the server sends a one line html document that
causes digester to throw a parse error.
try {
curDoc = digester.parse(curURL) ;
} catch ( Exception e ) {
System.out.println(No document found for + curURL );
}
In addition to throwing an exception the digester.parse() call will
also result in a stack trace when a parse error is encountered. Users
are getting confused by the trace information so I would like to
suppress it. I don't see any mention of this in digester docs, does
anyone know how to do it?
Thanks for any help or advice,
-=b
-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org
[Email] How to extend Email.send()
I'd like to extend the send() method of class Email (to enable some throttling custom error check + retry functionality) I'd love to just extend this and make it all seamless. It looks like there's this createMimeMessage() designed to allow something like this. But I'm not wrapping my brain around it. If this is possible could someone give me a quick point in the right direction on how I should extend Email.send()? Thanks much, David
Re: [exec] redirect output via command
Hi Thomas,
success stories are always welcome ... :-)
Cheers,
Siegfried Goeschl
On 23.08.10 22:09, Thomas Tanneberger wrote:
Hi Siegfried,
many thx for your advise. The solution is quite simple. You can open a
StreamWriter and write the output directly into. See example below.
code
PumpStreamHandler ps = new PumpStreamHandler(new FileOutputStream(
fileName));
executor.setStreamHandler(ps);
executor.execute(commandLine);
/code
Thomas
Am Freitag, den 13.08.2010, 11:14 +0200 schrieb Siegfried Goeschl:
Hi Thomas,
+) redirection such as out.txt is implemented in the command line
processor or shell. You would need a batch file to do that (a coule of
the regression tests are using that redirection)
+) executor.setStreamHandler(null) - should give you a NPE. Please
comment out the line. Without a stream handler you application will block.
+) Another was of getting the output is to use a StreamHandler and pass
a FileOutputStream.
Cheers,
Siegfried Goeschl
On 13.08.10 00:00, Thomas Tanneberger wrote:
Hi All,
while I am playing with Apache Common Exec I found out that is it
obviously not possible to redirect output into a file via command. I
want to exec cksum file file.chsum.txt. I get the output of cksum in
ecplise but it is not written to disk.
code
public static String CHKSUM_CMD2 = cksum \${FILE_NAME}\ out.txt;
HashMapString, String options = new HashMapString, String();
CommandLine commandLine = CommandLine.parse(CHKSUM_CMD2);
options.put(FILE_NAME, fileName);
commandLine.setSubstitutionMap(options);
DefaultExecutor executor = new DefaultExecutor();
executor.setStreamHandler(null);
executor.execute(commandLine);
/code
I suppose that I have to capture the output and write it to disk
afterwards. Or is there other solution ahead?
Many thx, Thomas
-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org
-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org
-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org
Re: [Email] How to extend Email.send()
Hi David, depends on what you would like to do - you can also check out http://turbine.apache.org/fulcrum/fulcrum-commonsemail/ how I use commons-email in a production environment. Cheers, Siegfried Goeschl On 23.08.10 21:48, David Parks wrote: I'd like to extend the send() method of class Email (to enable some throttling custom error check + retry functionality) I'd love to just extend this and make it all seamless. It looks like there's this createMimeMessage() designed to allow something like this. But I'm not wrapping my brain around it. If this is possible could someone give me a quick point in the right direction on how I should extend Email.send()? Thanks much, David - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
[ANNOUNCE] Commons Compress 1.1 released
The Commons Compress team is pleased to announce the commons-compress-1.1 release! Commons Compress defines an API for working with compression and archive formats. These include: bzip2, gzip and ar, cpio, jar, tar, zip. Source and binary distributions are available for download from the Apache Commons download site: http://commons.apache.org/compress/download_compress.cgi When downloading, please verify signatures using the KEYS file available at the above location when downloading the release. For more information on Apache Commons Compress, visit the Commons Compress home page: http://commons.apache.org/compress/ Changes in this version include: New features: o Command-line interface to list archive contents. Usage: java -jar commons-compress-n.m.jar archive-name [zip|tar|etc] Issue: COMPRESS-108. o Tar implementation does not support Pax headers Added support for reading pax headers. Note: does not support global pax headers Issue: COMPRESS-109. o ZipArchiveInputStream can optionally extract data that used the STORED compression method and a data descriptor. Doing so in a stream is not safe in general, so you have to explicitly enable the feature. By default the stream will throw an exception if it encounters such an entry. Issue: COMPRESS-103. o The ZIP classes will throw specialized exceptions if any attempt is made to read or write data that uses zip features not supported (yet). Issue: COMPRESS-98. o ZipFile#getEntries returns entries in a predictable order - the order they appear inside the central directory. A new method getEntriesInPhysicalOrder returns entries in order of the entry data, i.e. the order ZipArchiveInputStream would see. Issue: COMPRESS-99. o The Archive*Stream and ZipFile classes now have can(Read|Write)EntryData methods that can be used to check whether a given entry's data can be read/written. The method currently returns false for ZIP archives if an entry uses an unsupported compression method or encryption. o The ZIP classes now detect encrypted entries. Issue: COMPRESS-89. o Added autodetection of compression format to CompressorStreamFactory. Issue: COMPRESS-97. o Improve ExceptionMessages in ArchiveStreamFactory Issue: COMPRESS-95. Thanks to Joerg Bellmann. o A new constructor of TarArchiveEntry can create entries with names that start with slashes - the default is to strip leading slashes in order to create relative path names. o ArchiveEntry now has a getLastModifiedDate method. o Add a BZip2Utils class modelled after GZipUtils Issue: COMPRESS-78. Thanks to Jukka Zitting. Fixed Bugs: o Move acknowledgements from NOTICE to README Issue: COMPRESS-72. o TarArchiveEntry.parseTarHeader() includes the trailing space/NUL when parsing the octal size Issue: COMPRESS-113. o TarUtils.parseName does not properly handle characters outside the range 0-127 Issue: COMPRESS-118. o ArchiveStreamFactory does not recognise tar files created by Ant Issue: COMPRESS-107. o Support ustar prefix field, which is used when file paths are longer than 100 characters. Issue: COMPRESS-110. o ZipArchiveInputStream will throw an exception if it detects an entry that uses a data descriptor for a STORED entry since it cannot reliably find the end of data for this compression method. Issue: COMPRESS-100. o ZipArchiveInputStream should now properly read archives that use data descriptors but without the unofficial signature. Issue: COMPRESS-101. o ZipArchiveInputStream failed to update the number of bytes read properly. Issue: COMPRESS-74. o ArchiveInputStream has a new method getBytesRead that should be preferred over getCount since the later may truncate the number of bytes read for big archives. o The cpio archives created by CpioArchiveOutputStream couldn't be read by many existing native implementations because the archives contained multiple entries with the same inode/device combinations and weren't padded to a blocksize of 512 bytes. Issue: COMPRESS-85. o ZipArchiveEntry, ZipFile and ZipArchiveInputStream are now more lenient when parsing extra fields. Issue: COMPRESS-73. o cpio is terribly slow. Documented that buffered streams are needed for performance Issue: COMPRESS-82. o Improved exception message if the extra field data in ZIP archives cannot be parsed. o Tar format unspecified - current support documented. Issue: COMPRESS-17. o ZipArchiveEntry's equals method was broken for entries created with the String-arg constructor. This lead to broken ZIP archives if two different entries had the same hash code. Issue: COMPRESS-94. Thanks to Anon Devs. o ZipArchiveInputStream could repeatedly return 0 on read() when the archive was truncated. Issue: COMPRESS-87. Thanks to Antoni
